spm.js 模块生命周期解析
JS 模块的解析流程
目前解析是通过定义模块的生命周期来完成的，下面主要分析JS模块默认处理流程
资源输出（resources）
- 资源输出（resources）：在处理源码前，会把文件输出到 _build 一个临时目录中，然后后续对文件的操作都会在这个目录进行。我们在输出中也可以进行一些简单的变量替换。
- 预合并（combine）：允许对一个复杂的模块，进行物理拆分，也就是说拆分后的代码只有合并到一起了才是一个完整的模块。
编译（complie）
- 目前支持 coffee、less 等文件格式的处理
- 允许对第三方模块的 transport
- json 检查对 js 模块的处理
模块分析（analyse）
在这个阶段主要进行代码的语法检查（init），依赖分析（dependencies），依赖冲突检查（depCheck）等操作
依赖分析（dependencies）
- spm 会分析 _build 目录中的 js ，然后会计算出来这个模块的依赖模块列表，包括全局和相对模块
- 对于外部模块，还回去分析模块的依赖
- 有些模块是合并模块，spm 也会对依赖重复进行排除
- 对于外部模块的依赖列表进行全局化处理，也就是把原来的相对关系改成绝对关系
依赖冲突检测（depCheck）
主要检查统一模块中间不同版本的冲突检查
预打包（preBuild）
- 模板的处理，允许对 tpl、html 这类模板文件内嵌到 js 模块中
- css的处理， 允许样式内嵌到 js 模块中
合并处理（output）
主要就是按照output的配置，对模块合并输出
打包（build）
对模块进行统一的收尾工作
- min 模块压缩
- install 安装到本地缓存
- zip 是否打成 zip 包
上传到源中（upload）
- pack 默认打包成 tar 包，然后进行上传
- upload 会把 tar 包上传到我们配置的源中
部署到指定地方（deploy）
具体参考 spm deploy
上面看到的 resources、compile、analyse、preBuild、output、build 就是定义生命周期的各个阶段，而每个阶段中我们通过组合一系列插件来完成我们对应的工作。这样的一个好处就是通过这样的划分，我们可以很容易的把对应的任务产分到对应的地方。这样整个处理流程就完成了
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。